SSHクライアント & サーバーを実装しよう
概要
開催日時
2024年10月2日(月)、10月10日(火)、10月16日(月)..
16:45~19:45
タイトル
概要
開催日の5時間目は、メディアラボに集まります。
ノートPCを持参してください。
Dockerの環境構築ができていない方は、初回に行います。
本イベントで得られるもの
SSHを支える技術への理解
ハイブリッド暗号(RSA / AESを使用)
公開鍵認証
TCP/IP(BSDソケットを使用)
SSHをセキュアに利用する方法への理解
実装したクライアントが、中間者攻撃に対し適切な警告ができているか
実装したサーバーが、リプレイ攻撃から防御ができているか
架空の攻撃シナリオを元に、実装のセキュリティ上の問題を修正します
RFCを読んで実装する能力
SSH
本イベントの目的
SSHプロトコルを理解する
当たり前に存在するものではない
仕組みが気になりませんか?
前提知識
UNIX系OSのシェルを立ち上げ、ソフトウェアをダウンロードし、実行できる
サーバー、クライアントという言葉を知っており、それらが異なる役割を指すことを知っている
第1回 公開鍵暗号 ・ 自己紹介
🎈実際にアクセスする
今回の目標
ハイブリッド暗号の仕組みと、利点を説明できる
SSHプロトコル
SSHサーバーを起動している遠隔地のコンピュータに対して、シェルを利用できるようにする仕組み 共通鍵暗号方式
公開鍵暗号方式
共通鍵の問題点を解消できる方式
考え方
暗号に使う鍵では復号できないようにする
暗号化の目的は、平文を分からないようにすること
暗号化に使う鍵は流出しても構わない
復号に使う鍵は流出してはならない
RSA暗号
公開鍵暗号方式に用いられる暗号
累乗を使って暗号化・復号する
平文に暗号化鍵を累乗して、暗号文を得る
暗号文に復号鍵を累乗して、平文を得る
🎈RSA暗号を手計算で考える
🎈RSA暗号を実装する
ハイブリッド暗号
共通鍵暗号方式と公開鍵暗号方式の組み合わせ
共通鍵と公開鍵には、それぞれ利点と欠点がある
暗号化・復号には共通鍵を用いる
共通鍵は処理が高速
暗号化・復号に用いる共通鍵を、公開鍵暗号方式で伝送する
公開鍵は通信経路を信頼できなくても安全
共通鍵は、鍵の受け渡し問題さえ解決できれば、高速な暗号方式として利用できる
ハイブリッド暗号のフロー
共通鍵の安全な伝送
共通鍵の送信者は、共通鍵用の公開鍵を伝送する
共通鍵の送信者は、共通鍵用の秘密鍵で、共通鍵を暗号する
共通鍵の受信者は、共通鍵用の公開鍵で、暗号化された共通鍵を復号する
メッセージの伝送
一度共通鍵を伝送できたら、以降は複数のメッセージを共通鍵暗号方式で安全にやりとりできる
まとめ
SSHプロトコルはハイブリッド暗号を用いる
ハイブリッド暗号は、共通鍵暗号方式と、公開鍵暗号方式のそれぞれの利点を持つ
第2回 ソケット通信
BSDソケット
TCP/UDP通信を行えるUNIX系OSのAPI
第3回 SSHプロトコルの概観、今後の方針
TCP/IPの通信方法は、第2回で練習したとおり
ユーザー認証は、トランスポート層の上で動作する
https://scrapbox.io/files/64fddff03a2869001ba133db.png
SSH-ARCH読み合わせ
SSH-ARCHは、SSHの各層の関連性、および共通する概念を説明しています。
SSHのホスト鍵について
本人ですか?
通信の暗号化とは別に、ユーザーやサーバーが本物か認証が必要
公開鍵認証
公開鍵認証では、秘密鍵は「本人であること」を証明するための唯一的なデータ
秘密鍵は流出させてはならない
流出すれば、秘密鍵を得た他人が、秘密鍵を用いて認証を通過できる
公開鍵は流出してもよい
公開鍵は秘密鍵を検証するための道具に過ぎない
SSHでは、必然的にサーバーが持つことになる
ホスト鍵
クライアントが通信を始める際に、通信先が正しいサーバーであることを確かめるための公開鍵
認証されるのはサーバー
ホスト鍵によるサーバーの認証
サーバーは秘密鍵を持つ
秘密鍵は、サーバーが自身の真正性を証明するための唯一の道具
クライアントは公開鍵を持つ
サーバーは自身の公開鍵を伝送し、クライアントにサーバーを認証してもらう
サーバーはあるメッセージと、そのメッセージを秘密鍵で暗号化した暗号文を送る
クライアントは、サーバーから送られてきた暗号文を復号し、平文と同一か判定する
ホスト鍵の入手
クライアントは、事前にホスト鍵に入手し、データベースに登録する
データベースと書いたが、テキストファイルでもなんでもよい
サーバーにアクセスするための名前(例:root@127.0.0.1)と、サーバーの公開鍵の組を保存できればよい
または、初めてサーバーに接続を試みたときに、サーバーから送信される公開鍵を保存しておく
ホスト鍵の認証の流れ
今後の方針
下層から順番に実装していきます。
実装にあたっては、こちらでサポートを行います。
RFCを共に読み進めていきましょう。
RFCを元に実装できることが目標のため、写経は行いません。
実装が思いつかないとき
実装方法を一緒に考えましょう。
考える時間が重要です。
どうしても分からないときは、OpenSSHを読み、どのように書くのかを確認します。 /icons/hr.icon
興味ありiNoma.icon
対面でやりたい
ポータルで5人くらいを集めて、対面で行う予定ですt6o_o6t.icon
夏休みが明けて以降は、対面での企画を試す時間にしたい
いいね
企画してくれてありがとう!iNoma.icon
認証鍵
SSHへの接続を要求してきたユーザーが利用者本人かどうかをサーバーが判別するための鍵ペア。
🎈 認証鍵を設定してみよう
OpenSSHで、鍵ペアを生成する
id_rsa
秘密鍵
クライアントが保持する
id_rsa.pub
公開鍵
サーバーに置いておく
なぜ公開鍵をサーバーに置くのか
秘密鍵をクライアントが持つことで成り立っている
ホスト鍵に関するセキュリティの考慮事項
たとえばSSH-ARCHで、中間者攻撃の懸念について語られている
1つめのケース
2つめのケース
疑いをもたないユーザーが、攻撃者のホスト鍵を渡され、かつ中間者サーバーに接続してしまったら?
攻撃者は、自身の秘密鍵を用いて認証を済ませ、以降の通信を盗聴できる